Componentized embedded system information retrieval

ABSTRACT

Systems, methodologies, media, and other embodiments associated with collecting and providing data items that describe an element of an embedded system configured with a componentized operating system are described. One exemplary system embodiment includes a collection logic configured to collect the data item(s) from the embedded system that is configured with the componentized operating system. The collection logic may store the data item(s) in a data store. The example system may also include an access logic that provides access to the system data collected by the collection logic.

BACKGROUND

Embedded systems are generally characterized as including a hardwaredevice(s), a compact, reliable operating system that controls aprocessor(s) in the device, and a set of software applications that runon the operating system. An embedded system is typically a part of alarger system or machine. The compact operating system may be, forexample, a componentized version of a larger operating system. WindowsXP Embedded is an example of a componentized version of a largerrelative, Windows XP Professional. Componentizing an operating systemmay facilitate minimizing the resource (e.g., memory) demands placed onthe hardware by the operating system. Similarly, componentizing anoperating system may provide flexibility in deciding what functionalityto include in an embedded operating system. However, componentizing anoperating system, and then choosing a subset of the available componentsfor the embedded operating system may leave the embedded operatingsystem without some desired functionality. For example, in somecomponentized implementations, a component like msinfo32.exe that wouldtypically provide access to some system information may not beavailable. But users, systems administrators, test engineers, and so on,may still want to gather and examine system information about theirembedded system.

A “thin client” (e.g., computer with no moving parts), may form thehardware portion of an embedded system. A thin client may includeseveral hardware components like processors, memory, communicationdevices, and so on. A thin client user may wish to gather systeminformation about their system. A componentized operating system may beused to reduce the footprint (e.g., memory requirements) of theoperating system that runs on the thin client. Some of the componentsthat may be left out of a componentized operating system to reduce itsfootprint on a thin client may include management consoles and systeminformation collection/display utilities with which users are familiar.If some system information collection functionality is included, it maynot function properly if file dependencies required to implement thefunctionality are not satisfied (e.g., required dynamic link library(DLL) missing). Even if system information can be collected, a user maynot have a single point of contact with their embedded system throughwhich they can access the system information.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate various example systems, methods,and so on, that illustrate various example embodiments of aspects of theinvention. It will be appreciated that the illustrated elementboundaries (e.g., boxes, groups of boxes, or other shapes) in thefigures represent one example of the boundaries. One of ordinary skillin the art will appreciate that one element may be designed as multipleelements or that multiple elements may be designed as one element. Anelement shown as an internal component of another element may beimplemented as an external component and vice versa. Furthermore,elements may not be drawn to scale.

FIG. 1 illustrates an example system for retrieving system informationfrom an embedded system configured with a componentized operatingsystem.

FIG. 2 illustrates another example system for retrieving systeminformation from an embedded system configured with a componentizedoperating system.

FIG. 3 illustrates an example method for acquiring and providing systeminformation from an embedded system configured with a componentizedoperating system.

FIG. 4 illustrates another example method for acquiring and providingsystem information from an embedded system configured with acomponentized operating system.

FIG. 5 illustrates an example computing environment in which examplesystems and methods illustrated herein can operate.

FIG. 6 illustrates an example application programming interface (API).

FIG. 7 illustrates an example method associated with a graphical userinterface (GUI).

DETAILED DESCRIPTION

The following includes definitions of selected terms employed herein.The definitions include various examples and/or forms of components thatfall within the scope of a term and that may be used for implementation.The examples are not intended to be limiting. Both singular and pluralforms of terms may be within the definitions.

As used in this application, the term “computer component” refers to acomputer-related entity, either hardware, firmware, software, acombination thereof, or software in execution. For example, a computercomponent can be, but is not limited to being, a process running on aprocessor, a processor, an object, an executable, a thread of execution,a program, and a computer. By way of illustration, both an applicationrunning on a server and the server can be computer components. One ormore computer components can reside within a process and/or thread ofexecution and a computer component can be localized on one computerand/or distributed between two or more computers. An embedded system mayinclude several computer components.

“Computer-readable medium”, as used herein, refers to a medium thatparticipates in directly or indirectly providing signals, instructionsand/or data. A computer-readable medium may take forms, including, butnot limited to, non-volatile media, volatile media, and transmissionmedia. Non-volatile media may include, for example, optical or magneticdisks, and so on. Volatile media may include, for example, optical ormagnetic disks, dynamic memory and the like. Transmission media mayinclude coaxial cables, copper wire, fiber optic cables, and the like.Transmission media can also take the form of electromagnetic radiation,like that generated during radio-wave and infra-red data communications,or take the form of one or more groups of signals. Common forms of acomputer-readable medium include, but are not limited to, a floppy disk,a flexible disk, a hard disk, a magnetic tape, other magnetic medium, aCD-ROM, other optical medium, punch cards, paper tape, other physicalmedium with patterns of holes, a RAM, a ROM, an EPROM, a FLASH-EPROM, orother memory chip or card, a memory stick, a carrier wave/pulse, andother media from which a computer, a processor or other electronicdevice can read. Signals used to propagate instructions or othersoftware over a network, like the Internet, can be considered a“computer-readable medium.”

“Data store”, as used herein, refers to a physical and/or logical entitythat can store data. A data store may be, for example, a database, atable, a file, a list, a queue, a heap, a memory, a register, and so on.A data store may reside in one logical and/or physical entity and/or maybe distributed between two or more logical and/or physical entities.

“Logic”, as used herein, includes but is not limited to hardware,firmware, software and/or combinations of each to perform a function(s)or an action(s), and/or to cause a function or action from anotherlogic, method, and/or system. For example, based on a desiredapplication or needs, logic may include a software controlledmicroprocessor, discrete logic like an application specific integratedcircuit (ASIC), a programmed logic device, a memory device containinginstructions, or the like. Logic may include one or more gates,combinations of gates, or other circuit components. Logic may also befully embodied as software. Where multiple logical logics are described,it may be possible to incorporate the multiple logical logics into onephysical logic. Similarly, where a single logical logic is described, itmay be possible to distribute that single logical logic between multiplephysical logics. An embedded system may include several logics.

An “operable connection”, or a connection by which entities are“operably connected”, is one in which signals, physical communications,and/or logical communications may be sent and/or received. Typically, anoperable connection includes a physical interface, an electricalinterface, and/or a data interface, but it is to be noted that anoperable connection may include differing combinations of these or othertypes of connections sufficient to allow operable control. For example,two entities can be operably connected by being able to communicatesignals to each other directly or through one or more intermediateentities like a processor, operating system, a logic, software, or otherentity. Logical and/or physical communication channels can be used tocreate an operable connection.

“Signal”, as used herein, includes but is not limited to one or moreelectrical or optical signals, analog or digital signals, data, one ormore computer or processor instructions, messages, a bit or bit stream,or other means that can be received, transmitted and/or detected.

“Software”, as used herein, includes but is not limited to, one or morecomputer or processor instructions that can be read, interpreted,compiled, and/or executed and that cause a computer, processor, or otherelectronic device to perform functions, actions and/or behave in adesired manner. The instructions may be embodied in various forms likeroutines, algorithms, modules, methods, threads, and/or programsincluding separate applications or code from dynamically and/orstatically linked libraries. Software may also be implemented in avariety of executable and/or loadable forms including, but not limitedto, a stand-alone program, a function call (local and/or remote), aservelet, an applet, instructions stored in a memory, part of anoperating system or other types of executable instructions. It will beappreciated by one of ordinary skill in the art that the form ofsoftware may depend, for example, on requirements of a desiredapplication, the environment in which it runs, and/or the desires of adesigner/programmer or the like. It will also be appreciated thatcomputer-readable and/or executable instructions can be located in onelogic and/or distributed between two or more communicating,co-operating, and/or parallel processing logics and thus can be loadedand/or executed in serial, parallel, massively parallel and othermanners.

Suitable software for implementing the various components of the examplesystems and methods described herein may be produced using programminglanguages and tools like Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs,SDKs, assembly, firmware, microcode, and/or other languages and tools.Software, whether an entire system or a component of a system, may beembodied as an article of manufacture and maintained or provided as partof a computer-readable medium as defined previously. Another form of thesoftware may include signals that transmit program code of the softwareto a recipient over a network or other communication medium. Thus, inone example, a computer-readable medium has a form of signals thatrepresent the software/firmware as it is downloaded from a web server toa user. In another example, the computer-readable medium has a form ofthe software/firmware as it is maintained on the web server. Other formsmay also be used.

“User”, as used herein, includes but is not limited to one or morepersons, software, computers or other devices, or combinations of these.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a memory. These algorithmic descriptions and representationsare the means used by those skilled in the art to convey the substanceof their work to others. An algorithm is here, and generally, conceivedto be a sequence of operations that produce a result. The operations mayinclude physical manipulations of physical quantities. Usually, thoughnot necessarily, the physical quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated in a logic and the like.

It has proven convenient at times, principally for reasons of commonusage, to refer to these signals as bits, values, elements, symbols,characters, terms, numbers, or the like. It should be borne in mind,however, that these and similar terms are to be associated with theappropriate physical quantities and are merely convenient labels appliedto these quantities. Unless specifically stated otherwise, it isappreciated that throughout the description, terms like processing,computing, calculating, determining, displaying, or the like, refer toactions and processes of a computer system, logic, processor, or similarelectronic device that manipulates and transforms data represented asphysical (electronic) quantities.

FIG. 1 illustrates a system 100 that includes a collection logic 110that is configured to collect a system data from an embedded system 120that is configured with a componentized operating system 130. In oneexample, embedded system 120 may be a specialized computer system thatis part of a larger system or machine. An embedded system may, forexample, be housed on a microprocessor board. The board may include aread-only memory (ROM) in which programs run by the embedded system arestored. A microprocessor board that controls an automobile anti-lockbrake system is one example of an embedded system. Embedded systemstypically respond to events in real time.

The system data may include, for example, information concerning randomaccess memory (RAM) associated with the embedded system 120. The RAMinformation may include, for example, the amount, type, and/or locationof RAM associated with the embedded system 120. While amount, type,and/or location are described, it is to be appreciated that other RAMinformation may be acquired and/or made available. The system data mayalso include, for example, information concerning flash memoryassociated with the embedded system 120. The flash memory informationmay include, for example, the amount and type of flash memory associatedwith the embedded system 120 and a name for a logical drive implementedby the flash memory. While amount, type, and logical names for “diskdrives” implemented in flash memory are described, it is to beappreciated that other information about flash memory may be acquired,provided, and/or displayed. The system data may also include informationconcerning the manufacturer (e.g., website address, name, telephonenumber) of the embedded system 120, a product name assigned to theembedded system 120, a serial number assigned to the embedded system120, and the like. The system data may also include informationconcerning read only memory (ROM) associated with the embedded system120. The ROM information may include, for example, a ROM version, a ROMrelease date, a ROM manufacture date, a ROM manufacturer, a ROM size, aROM type, a ROM location, and the like. The system data may also includeinformation concerning the componentized operating system 130, like anoperating system version, name, manufacturer, product identifier, systemimage identifier, version date, and the like. The system data may alsoinclude information concerning a hardware device(s) (e.g., networkadapter) included in the embedded system 120. The hardware device datamay include, for example, a hardware device name, type, address,interrupt vector, power requirement, and so on.

The collection logic 110 may be configured to acquire the system datasince the componentized operating system 130 may not include logic toacquire the data. For example, a componentized operating system 130developed from Microsoft Windows XP Embedded may not include logic forexamining the hardware, software, and firmware in the embedded system120. Even if the componentized operating system 130 includes some suchlogic, it may not be configured to store the retrieved information in asingle location and to provide a single point of contact for a user whodesires to access the data. In one example, the collection logic 110 isconfigured to collect all the types of system data described above.However, in other examples, the collection logic 110 may be configuredto collect subsets of the system data. Furthermore, the collection logic110 may be dynamically reconfigurable to facilitate collecting differentsubsets of system data under different conditions.

The collection logic 110 may acquire the system data from a variety ofelements including hardware, firmware, and/or software associated withthe embedded system 120. Thus, the collection logic 110 may interactwith various logics to collect the system data. For example, thecollection logic 110 may access a system management BIOS (SMBIOS)associated with the embedded system 120 to collect hardware-relatedmanagement information in a standardized format. The informationacquired through the SMBIOS may include, for example, BIOS information(e.g., version, release date), manufacturer and product name strings,processor type information, cache information (e.g., installed size),system slot data (e.g., type, bus width, slot identifier), physicalmemory information (e.g., location, use, memory error correction,maximum capacity), memory device information, and so on. In one example,the SMBIOS may be an SMBIOS like that described by the DistributedManagement Task Force (DMTF) in the SMBIOS version 2.3.4 specification.While the DMTF version 2.3.4 specification is described, it is to beappreciated that in some examples other SMBIOS versions may be employed.

The collection logic 110 may also interact with an applicationprogramming interface (API) associated with the componentized operatingsystem 130. For example, the componentized operating system 130 maypublish interfaces to various dynamic link libraries (DLLs) thatfacilitate acquiring a piece of system information. Thus, the collectionlogic 110 may determine whether there is a published interface, and ifso, may employ it to acquire the data. The collection logic 110 mayalso, for example, examine a registry associated with the componentizedoperating system 130, examine a file system associated with thecomponentized operating system 130, examine a file associated with thecomponentized operating system 130, communicate with a hardwaredevice(s) included in the embedded system 120, and so on. The collectionlogic 110 may examine the registry to determine, for example, whatsoftware applications, if any, have been installed, updated,uninstalled, and so on, on the embedded system.

The collection logic 110 may be configured to store the system data in adata store 140. The data store 140 may be, for example, a file that canbe read by a user or by a display application. In one example, thecollection logic 110 may store the system data in an XML (extensiblemarkup language) record to facilitate making the data widely available.In another example, the data store 140 may be a memory that is writeableby the collection logic 110 and/or embedded system 120 and readable by adisplay application. Since an embedded system 120 like an anti-lockbrake system may not have a display, the collection logic 110 may storethe system data in a location that is accessible to a displayapplication.

The system 100 may also include an access logic 150 that is configuredto provide access to the system data stored in the data store 140. Theaccess logic 150 may provide a programmatic interface that facilitatesaccessing the system data stored in the data store 140. For example, theaccess logic 150 may publish an interface that facilitates other logicsrequesting system data stored in the data store 140 without requiringthem to become familiar with the internal layout of the data store 140.In one example, the access logic 150 may provide the system data to asupport information window in a Microsoft system information controlpanel applet provided by Microsoft Windows XP Embedded. While thecollection logic 110 and the access logic 150 are illustrated outsidethe embedded system 120, it is to be appreciated that in one example,either the collection logic 110 and/or the access logic 150 may be partof the embedded system 120.

FIG. 2 illustrates a system 200 for retrieving system information froman embedded system 210 that is configured with a componentized operatingsystem 220. The system 200 includes a collection logic 230 that isconfigured to collect a system data from the embedded system 210. Thecomponentized operating system 220 may be assembled from a set ofcomponents available in a parent operating system. For example, thecomponentized operating system 220 may be derived from a parentoperating system like Microsoft Windows XP Embedded. While a singlecomponent in a componentized operating system may be able to acquireand/or provide information concerning its operation, components in acomponentized operating system typically work independently, making itdifficult to coordinate system data collection and providing a singlepoint of contact.

The system data may include information concerning random access memory(RAM) 240 associated with the embedded system 210, flash memory 250associated with the embedded system 210, read only memory (ROM) 260associated with the embedded system 210, the componentized operatingsystem 220, hardware device(s) 270 included in the embedded system 210,and so on. The collection logic 220 may be configured to store thesystem data in a data store 280 after collecting the system data byinteracting with a variety of logics. For example, the collection logic230 may access a system management BIOS (SMBIOS) 290 associated with theembedded system 210, may access an application programming interface(API) 292 associated with the componentized operating system 220, andmay examine a registry 294 associated with the componentized operatingsystem 220. Similarly, the collection logic 230 may undertake otheractions like examining a file system (not illustrated) associated withthe componentized operating system 220, and communicating with adevice(s) 270 associated with the embedded system 210. Accessing theSMBIOS 290 may include, for example, reading a formatted data block froma memory associated with the SMBIOS 290. Accessing the API 292 mayinclude, for example, making a procedure call using a procedure entrypoint defined by the API 292. Examining the registry 294 may include,for example, making a query to a registry database management system.

The system 200 may also include an access logic 296 that is configuredto provide the system data to a support information window in aMicrosoft system information control panel applet provided by thecomponentized operating system 220. Since a user may be familiar withthe system information control panel, the access logic 296 may selectthe applet providing the system information control panel for producingan intuitive single point of contact for a user seeking to view thesystem data.

Example methods may be better appreciated with reference to the flowdiagrams of FIGS. 3 and 4. While for purposes of simplicity ofexplanation, the illustrated methodologies are shown and described as aseries of blocks, it is to be appreciated that the methodologies are notlimited by the order of the blocks, as some blocks can occur indifferent orders and/or concurrently with other blocks from that shownand described. Moreover, less than all the illustrated blocks may berequired to implement an example methodology. Furthermore, additionaland/or alternative methodologies can employ additional, not illustratedblocks.

In the flow diagrams, blocks denote “processing blocks” that may beimplemented with logic. The processing blocks may represent a methodstep and/or an apparatus element for performing the method step. A flowdiagram does not depict syntax for any particular programming language,methodology, or style (e.g., procedural, object-oriented). Rather, aflow diagram illustrates functional information one skilled in the artmay employ to develop logic to perform the illustrated processing. Itwill be appreciated that in some examples, program elements liketemporary variables, routine loops, and so on, are not shown. It will befurther appreciated that electronic and software applications mayinvolve dynamic and flexible processes so that the illustrated blockscan be performed in other sequences that are different from those shownand/or that blocks may be combined or separated into multiplecomponents. It will be appreciated that the processes may be implementedusing various programming approaches like machine language, procedural,object oriented and/or artificial intelligence techniques.

FIG. 3 illustrates an example method 300 for acquiring and providingsystem information from an embedded system configured with acomponentized operating system. Embedded systems configured with intactmonolithic operating systems likely contain a set of applications and/orutilities designed to collect system information. However, acomponentized operating system may not include such utilities. Even if aconventional embedded system does provide for acquiring some systeminformation, it typically does not facilitate providing a user with anintuitive single point of contact for accessing the data.

Thus, the method 300, which may be performed in an embedded system, mayinclude, at 310, acquiring a set of descriptive data from the embeddedsystem. The descriptive data may describe, for example, hardware,software, and/or firmware components of the embedded system. In oneexample, acquiring the set of descriptive data includes accessing asystem management BIOS (SMBIOS) associated with the embedded system,accessing an application programming interface (API) associated with thecomponentized operating system, examining a registry associated with thecomponentized operating system, examining a file system associated withthe componentized operating system, and communicating with a deviceincluded in the embedded system. In other examples, acquiring the set ofdescriptive data may include performing a subset of the actionsdescribed above. Accessing the SMBIOS may involve, for example, making aprocedure and/or function call to an SMBIOS provided in the embeddedsystem. Similarly, accessing a componentized operating system API mayinvolve, for example, making a procedure and/or function call to the APIto acquire data from the operating system. Examining the registry mayinclude, for example, opening a registry-type file, searching forvarious entries, and closing the registry-type file. Communicating witha device may include, for example, passing a message to the device,reading a memory-mapped location associated with the device, sending asignal (e.g., interrupt) to the device, and so on.

The method 300 may also include, at 320, making the set of descriptivedata available to a user. The set of descriptive data may include, forexample, information concerning embedded system random access memory(RAM), embedded system flash memory, the manufacturer of the embeddedsystem, the embedded system product name, the embedded system serialnumber, embedded system read only memory (ROM), and so on. While severaltypes of system information are described, it is to be appreciated thatother system-type data may be acquired and/or displayed by method 300.

In one example, making the set of descriptive data available to a userincludes storing the set of descriptive data in a data store. The datastore may be, for example, a file that is readable by a user program. Inanother example, making the set of descriptive data available to a userincludes providing the set of descriptive data to a viewing component ofthe componentized operating system. The viewing component may be, forexample, a support information window in a Microsoft system informationcontrol panel applet in a componentized operating system derived fromMicrosoft Windows XP Embedded. In still another example, making the setof descriptive data available to a user includes providing aprogrammatic interface that facilitates programmatically acquiring theset of descriptive data from the data store.

While FIG. 3 illustrates various actions occurring in serial, it is tobe appreciated that various actions illustrated in FIG. 3 could occursubstantially in parallel. By way of illustration, a first process couldacquire the descriptive data while a second process could make the dataavailable. While two processes are described, it is to be appreciatedthat a greater and/or lesser number of processes could be employed andthat lightweight processes, regular processes, threads, and otherapproaches could be employed. It is to be appreciated that other examplemethods may, in some cases, also include actions that occursubstantially in parallel.

FIG. 4 illustrates an example method 400 for acquiring and providingsystem information from an embedded system configured with acomponentized operating system. The method 400 facilitates producing asingle point of contact for a user to access system informationdescribing elements of the embedded system configured with thecomponentized operating system. The method 400 may include, at 410,acquiring and selectively writing an embedded system manufacturer data(e.g., name) to a user viewable location. The user viewable location maybe, for example, a display window, a file, a memory, and so on. Themanufacturer data may be acquired by the method 400 (e.g., by accessingthe SMBIOS) and/or may be provided to the method 400. Thus, the method400 may, in some examples, pull data to it and in other examples mayhave data pushed to it.

The method 400 may also include, at 420, acquiring and selectivelywriting an embedded system manufacturer Uniform Resource Locator (URL)to the user viewable location. Like the manufacturer data written at410, in one example the URL written at 420 may be pulled to the method400 while in another example the URL may be pushed to the method 400.While a manufacturer name and URL are described, it is to be appreciatedthat other manufacturer data like address, phone number, and so on, maybe acquired and stored (e.g., written).

The method 400 may also include, at 430, retrieving data like a productname, a serial number, a ROM version, a ROM data, and a RAM data for theembedded system via an SMBIOS associated with the embedded system. Whilefive items are described, it is to be appreciated that a greater and/orlesser number of data items may be retrieved via the SMBIOS. At 440, thedata acquired at 430 may be selectively written to the user viewablelocation. Which data is written at 440 may be controlled, for example,by settings in a user preference data.

The method 400 may also include, at 450, acquiring data like anoperating system version data and a product identifier data via anapplication programming interface (API) associated with thecomponentized operating system. At 460, the data acquired at 450 may beselectively written to the user viewable location. While two items aredescribed, it is to be appreciated that a greater and/or lesser numberof data items may be retrieved via the API.

The method 400 may also include, at 470, accessing a hardware deviceincluded in the embedded system to acquire a hardware device data. Inone example, a networking card may be queried to determine its MACaddress and IP address. In another example, a memory card may be queriedto determine its size and availability. In yet another example, amechanical device like a servo that is controlled by the embedded systemmay be queried to provide data like status, position, and so on. While anetwork card and a memory card are described, it is to be appreciatedthat other devices associated with an embedded system may be queried.The information collected at 470 may be selectively written to the userviewable location.

At 480, the method 400 may access a registry associated with thecomponentized operating system to acquire a pre-installed software data.For example, the registry may contain information concerning whichapplications, if any, have been pre-installed, installed, updated,uninstalled, and so on, from the embedded system. The informationcollected at 480 may be selectively written to the user viewablelocation. “Registry” as used herein refers to the logic and datastructures collectively referred to as a registry in the Microsoftoperating system environment. For example, a registry may store setupinformation concerning the hardware, software, and operating system in asystem. Information may be stored in a registry, for example, by controlpanel applications or setup routines associated with various softwareapplications. In one example, a registry is examined using the regeditutility.

In one example, methodologies are implemented as processor executableinstructions and/or operations stored on a computer-readable medium.Thus, in one example, a computer-readable medium may store processorexecutable instructions operable to perform a method performed by anembedded system configured with a componentized operating system derivedfrom Microsoft Windows XP Embedded. The method may include acquiring aset of descriptive data from the embedded system by accessing a systemmanagement BIOS (SMBIOS) associated with the embedded system, accessingan application programming interface (API) associated with thecomponentized operating system, examining a registry associated with thecomponentized operating system, examining a file system associated withthe componentized operating system, and communicating with a deviceincluded in the embedded system. The set of descriptive data that isacquired may include information concerning random access memory (RAM)associated with the embedded system, flash memory associated with theembedded system, an embedded system manufacturer, a product name for theembedded system, a serial number for the embedded system, read onlymemory (ROM) associated with the embedded system, a hardware device(s)included in the embedded system, and so on. The method may also includemaking the set of descriptive data available to a user by, for example,providing the set of descriptive data to a viewing component of thecomponentized operating system and providing a programmatic interfacethat facilitates acquiring the set of descriptive data from the datastore. While the above method is described being stored on acomputer-readable medium, it is to be appreciated that other examplemethods described herein can also be stored on a computer-readablemedium.

FIG. 5 illustrates an embedded system 500 configured with acomponentized operating system. The system 500 includes a processor 502,a memory 504, and input/output ports 510 operably connected by a bus508. In one example, the embedded system 500 may include a componentizedembedded system information retrieval logic 530 configured to facilitateacquiring and providing system information about various components ofembedded system 500. Thus, the componentized embedded system informationretrieval logic 530, whether implemented in embedded system 500 ashardware, firmware, software, and/or a combination thereof, may providemeans for acquiring a hardware data from the embedded system 500. Thehardware data may describe a hardware component (e.g., processor 502) ofthe embedded system 500. The componentized embedded system informationretrieval logic 530 may also provide means for acquiring a firmware datafrom the embedded system 500, where the firmware data describes afirmware component (e.g., ROM BIOS) of the embedded system 500, andmeans for acquiring a software data from the embedded system 500, wherethe software data describes a software component (e.g., applicationrunning as process 514) of the embedded system 500. While thecomponentized embedded system information retrieval logic 530 mayacquire the hardware, firmware, and software data, it may also providemeans for providing the hardware data, the firmware data, and thesoftware data to a single location accessible by a user. For example,the componentized embedded system information retrieval logic 530 mayplace the hardware, firmware, and software data into a file that can beread by a user (e.g., an XML file), may deliver the data to a viewingapplet, may store the data in a memory that can be accessed by an API,and so on.

The processor 502 can be a variety of various processors including dualmicroprocessor and other multi-processor architectures. The memory 504can include volatile memory and/or non-volatile memory. The non-volatilememory can include, but is not limited to, ROM, PROM, EPROM, EEPROM, andthe like. Volatile memory can include, for example, RAM, synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), and direct RAM bus RAM (DRRAM).

The memory 504 can store processes 514 and/or data 516, for example. Thememory 504 can store a componentized operating system that controls andallocates resources of the embedded system 500. The componentizedoperating system may be derived from (e.g., built from) Windows XPEmbedded, for example. In one example, the embedded system informationretrieval logic 530 may be configured to acquire/provide data (e.g.,size, type, location) concerning elements like memory 504.

The bus 508 can be a single internal bus interconnect architectureand/or other bus or mesh architectures. While a single bus isillustrated, it is to be appreciated that embedded system 500 maycommunicate with various devices, logics, and peripherals using otherbusses that are not illustrated (e.g., PCIE, SATA, Infiniband, 1394,USB, Ethernet). The bus 508 can be of a variety of types including, butnot limited to, a memory bus or memory controller, a peripheral bus orexternal bus, a crossbar switch, and/or a local bus. The local bus canbe of varieties including, but not limited to, an industrial standardarchitecture (ISA) bus, a microchannel architecture (MSA) bus, anextended ISA (EISA) bus, a peripheral component interconnect (PCI) bus,a universal serial (USB) bus, and a small computer systems interface(SCSI) bus.

The embedded system 500 can operate in a network environment and thusmay be connected to network devices 520 via the i/o interfaces 518,and/or the i/o ports 510. Through the network devices 520, the embeddedsystem 500 may interact with a network. Through the network, theembedded system 500 may be logically connected to remote computers. Thenetworks with which the embedded system 500 may interact include, butare not limited to, a local area network (LAN), a wide area network(WAN), and other networks. The network devices 520 can connect to LANtechnologies including, but not limited to, fiber distributed datainterface (FDDI), copper distributed data interface (CDDI), Ethernet(IEEE 802.3), token ring (IEEE 802.5), wireless computer communication(IEEE 802.11), Bluetooth (IEEE 802.15.1), Zigbee (IEEE 802.15.4) and thelike. Similarly, the network devices 520 can connect to WAN technologiesincluding, but not limited to, point to point links, circuit switchingnetworks like integrated services digital networks (ISDN), packetswitching networks, and digital subscriber lines (DSL). In one example,the embedded system information retrieval logic 530 may be configured toacquire data (e.g., MAC address, IP address) from the network devices520. In another example, the embedded system information retrieval logic530 may be configured to store system data and make it available toremote computers via the network devices 520.

Referring now to FIG. 6, an application programming interface (API) 600is illustrated providing access to a system 610 for acquiring andproviding system information associated with an embedded systemconfigured with a componentized operating system. The API 600 can beemployed, for example, by a programmer 620 and/or a process 630 to gainaccess to processing performed by the system 610. For example, aprogrammer 620 can write a program to access the system 610 (e.g.,invoke its operation, monitor its operation, control its operation)where writing the program is facilitated by the presence of the API 600.Rather than programmer 620 having to understand the internals of thesystem 610, the programmer 620 merely has to learn the interface to thesystem 610. This facilitates encapsulating the functionality of thesystem 610 while exposing that functionality. Similarly, the API 600 canbe employed to provide data values to the system 610 and/or retrievedata values from the system 610. For example, a process 630 thatacquires system information can provide it to the system 610 via the API600 by, for example, using a call provided in the API 600.

In one example, a set of application programming interfaces can bestored on a computer-readable medium. The interfaces can be employed bya programmer, logic, and so on, to gain access to a system 610 foracquiring and providing system information associated with an embeddedsystem that is configured with a componentized operating system. Theinterfaces can include, but are not limited to, a first interface 640that communicates a first identifier that identifies a system data tocollect and a second interface 650 that communicates a second identifierthat identifies a system data to provide. For example, the firstidentifier may indicate that information concerning RAM associated withan embedded system is to be acquired. There may be several pieces ofinformation about RAM available (e.g., size, speed, type, logic) thatcan be acquired with a single SMBIOS call. Thus, the second identifiermay facilitate selecting one element of the acquired data (e.g., RAMsize) to provide.

FIG. 7 illustrates an example method 700 concerning operationsassociated with collecting and displaying a data item(s) that describesan element of an embedded system configured with a componentizedoperating system. The method 700 may be performed in a computer systemhaving a graphical user interface that includes a display and aselection device. The method 700 may include providing and selectingfrom a set of data entries on the display. Thus, in one example, themethod 700 may include, at 710, retrieving a set of data entries, wherea data entry represents an operation associated with collecting and/ordisplaying the data item that describes an embedded system element(e.g., RAM, processor, operating system, loaded applications). Themethod 700 may also include, at 720, displaying the set of data entrieson the display and, at 730, receiving a data entry selection signalindicative of the selection device selecting an entry. For example, auser may indicate that of twenty possible pieces of system information,a subset of ten items is to be acquired and displayed. The data entryselection signal may be received in response to, for example, a mouseclick, a key press, a voice command, and so on. At 740, in response tothe data entry selection signal, the method 700 may initiate a datacollection and/or display operation associated with the selected dataentry. In one example, a determination is made at 750 concerning whetheranother data entry selection signal is to be processed. If thedetermination is Yes, then processing returns to 730, otherwise, method700 may complete. Thus, the method 700 may facilitate identifying systeminformation to acquire and/or display. For example, the method 700 mayfacilitate displaying a set of system information that can be acquired,selectively acquiring a selected subset of the set of systeminformation, and providing the acquired system information to an applettasked with displaying the data.

While example systems, methods, and so on, have been illustrated bydescribing examples, and while the examples have been described inconsiderable detail, it is not the intention of the applicants torestrict or in any way limit the scope of the appended claims to suchdetail. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe systems, methods, and so on, described herein. Additional advantagesand modifications will readily appear to those skilled in the art.Therefore, the invention is not limited to the specific details, therepresentative apparatus, and illustrative examples shown and described.Thus, this application is intended to embrace alterations,modifications, and variations that fall within the scope of the appendedclaims. Furthermore, the preceding description is not meant to limit thescope of the invention. Rather, the scope of the invention is to bedetermined by the appended claims and their equivalents.

To the extent that the term “includes” or “including” is employed in thedetailed description or the claims, it is intended to be inclusive in amanner similar to the term “comprising” as that term is interpreted whenemployed as a transitional word in a claim. Furthermore, to the extentthat the term “or” is employed in the detailed description or claims(e.g., A or B) it is intended to mean “A or B or both”. When theapplicants intend to indicate “only A or B but not both” then the term“only A or B but not both” will be employed. Thus, use of the term “or”herein is the inclusive, and not the exclusive use. See, Bryan A.Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).

1. A system, comprising: a collection logic configured to collect asystem data from an embedded system configured with a componentizedoperating system and to store the system data in a data store; and anaccess logic configured to provide access to the system data stored inthe data store.
 2. The system of claim 1, where the system data includesinformation concerning random access memory (RAM) associated with theembedded system, flash memory associated with the embedded system, anembedded system manufacturer, a product name for the embedded system, aserial number for the embedded system, read only memory (ROM) associatedwith the embedded system, the componentized operating system, and ahardware device included in the embedded system.
 3. The system of claim2, where information concerning RAM associated with the embedded systemincludes information about one or more of, an amount of RAM associatedwith the embedded system, a type of RAM associated with the embeddedsystem, and a location of RAM associated with the embedded system. 4.The system of claim 2, where information concerning flash memoryassociated with the embedded system includes information about one ormore of, an amount of flash memory associated with the embedded system,a type of flash memory associated with the embedded system, and a namefor a logical drive implemented in the flash memory.
 5. The system ofclaim 2, where information concerning an embedded system manufacturerincludes information about one or more of, a manufacturer websiteaddress, a manufacturer name, and a manufacturer telephone number. 6.The system of claim 2, where information concerning ROM associated withthe embedded system includes information about one or more of, a ROMversion, a ROM release date, a ROM manufacture date, a ROM manufacturer,a ROM size, a ROM type, and a ROM location.
 7. The system of claim 2,where information concerning the componentized operating system includesinformation about one or more of, an operating system version, anoperating system name, an operating system manufacturer, an operatingsystem product identifier, an operating system image identifier, and anoperating system date.
 8. The system of claim 2, where informationconcerning a hardware device included in the embedded system includesinformation about one or more of, a hardware device name, a hardwaredevice type, a hardware device address, a hardware device interruptvector, and a hardware device power requirement.
 9. The system of claim1, where the system data includes information concerning two or more of,random access memory (RAM) associated with the embedded system, flashmemory associated with the embedded system, an embedded systemmanufacturer, a product name for the embedded system, a serial numberfor the embedded system, read only memory (ROM) associated with theembedded system, the componentized operating system, and a hardwaredevice included in the embedded system.
 10. The system of claim 2, wherethe collection logic is configured to collect the system data byaccessing a system management BIOS (SMBIOS) associated with the embeddedsystem, by accessing an application programming interface (API)associated with the componentized operating system, by examining aregistry associated with the componentized operating system, byexamining a file system associated with the componentized operatingsystem, by examining a file associated with the componentized operatingsystem, and by communicating with a hardware device associated with theembedded system.
 11. The system of claim 9, where the collection logicis configured to collect the system data by performing two or more of,making a call to a system management BIOS (SMBIOS) associated with theembedded system, by making a call to an application programminginterface (API) associated with the componentized operating system, byexamining a registry associated with the componentized operating system,by examining a file system associated with the componentized operatingsystem, by examining a file associated with the componentized operatingsystem, and by communicating with a device associated with the embeddedsystem.
 12. The system of claim 1, where the collection logic stores thesystem data as an XML file in the data store.
 13. The system of claim 1,where the access logic provides a programmatic interface thatfacilitates accessing the system data stored in the data store.
 14. Thesystem of claim 1, where the collection logic and the access logic arehardware components forming part of the embedded system.
 15. The systemof claim 1, the componentized operating system being Microsoft WindowsXP Embedded.
 16. The system of claim 15, where the access logic providesthe system data to a support information window in a Microsoft systeminformation control panel applet provided by Microsoft Windows XPEmbedded.
 17. A system, comprising: a collection logic configured tocollect a system data from an embedded system configured with acomponentized operating system derived from Microsoft Windows XPEmbedded, where the system data includes information concerning randomaccess memory (RAM) associated with the embedded system, flash memoryassociated with the embedded system, an embedded system manufacturer, aproduct name for the embedded system, a serial number for the embeddedsystem, read only memory (ROM) associated with the embedded system, anoperating system associated with the embedded system, and a hardwaredevice included in the embedded system, where the collection logic isconfigured to store the system data in a data store; where thecollection logic is also configured to collect the system data byaccessing a system management BIOS (SMBIOS) associated with the embeddedsystem, by accessing an application programming interface (API)associated with the componentized operating system, by examining aregistry associated with the componentized operating system, byexamining a file system associated with the componentized operatingsystem, and by communicating with a device associated with the embeddedsystem; and an access logic configured to provide the system data to asupport information window in a Microsoft system information controlpanel applet provided by the componentized operating system.
 18. Acomputer-executable method performed in an embedded system, comprising:acquiring a set of descriptive data from the embedded system, where theembedded system is configured with a componentized operating system, andwhere the descriptive data describes a hardware, software, or firmwarecomponent of the embedded system; and making the set of descriptive dataavailable to a user.
 19. The method of claim 18, where acquiring the setof descriptive data includes accessing a system management BIOS (SMBIOS)associated with the embedded system, accessing an applicationprogramming interface (API) associated with the componentized operatingsystem, examining a registry associated with the componentized operatingsystem, examining a file system associated with the componentizedoperating system, and communicating with a device included in theembedded system.
 20. The method of claim 18, where acquiring the set ofdescriptive data includes performing two or more of, accessing a systemmanagement BIOS (SMBIOS) associated with the embedded system, accessingan application programming interface (API) associated with thecomponentized operating system, examining a registry associated with thecomponentized operating system, examining a file system associated withthe componentized operating system, and communicating with a deviceincluded in the embedded system.
 21. The method of claim 18, where theset of descriptive data includes information concerning random accessmemory (RAM) associated with the embedded system, flash memoryassociated with the embedded system, an embedded system manufacturer, aproduct name for the embedded system, a serial number for the embeddedsystem, read only memory (ROM) associated with the embedded system, anoperating system associated with the embedded system, and a hardwaredevice included in the embedded system.
 22. The method of claim 18,where making the set of descriptive data available to a user includesstoring the set of descriptive data in a data store as an extensiblemarkup language (XML) file.
 23. The method of claim 18, where making theset of descriptive data available to a user includes providing the setof descriptive data to a viewing component of the componentizedoperating system.
 24. The method of claim 23, where the viewingcomponent comprises a support information window in a Microsoft systeminformation control panel applet in a componentized operating systemderived from Microsoft Windows XP Embedded.
 25. The method of claim 18,where making the set of descriptive data available to a user includesproviding a programmatic interface that facilitates programmaticallyacquiring the set of descriptive data from the data store.
 26. Acomputer-readable medium storing processor executable instructionsoperable to perform a method in an embedded system configured with acomponentized operating system, the method comprising: acquiring a setof descriptive data from the embedded system by accessing a systemmanagement BIOS (SMBIOS) associated with the embedded system, accessingan application programming interface (API) associated with thecomponentized operating system, examining a registry associated with thecomponentized operating system, examining a file system associated withthe componentized operating system, and communicating with a deviceincluded in the embedded system, where the set of descriptive dataincludes information concerning random access memory (RAM) associatedwith the embedded system, flash memory associated with the embeddedsystem, an embedded system manufacturer, a product name for the embeddedsystem, a serial number for the embedded system, read only memory (ROM)associated with the embedded system, an operating system associated withthe embedded system, and a hardware device included in the embeddedsystem; and making the set of descriptive data available to a user byone or more of, providing the set of descriptive data to a viewingcomponent of the componentized operating system, providing aprogrammatic interface that facilitates acquiring the set of descriptivedata from a data store, and storing the set of descriptive data in anXML file.
 27. A method for producing a single point of contact for auser to access system information describing elements of an embeddedsystem configured with a componentized operating system, the methodcomprising: selectively writing an embedded system manufacturer data toa user viewable location; retrieving a product name, a serial number, aROM version, a ROM data, and a RAM data for the embedded system via anSMBIOS associated with the embedded system; selectively writing theproduct name, serial number, ROM version, ROM data, and RAM data to theuser viewable location; acquiring an operating system version data and aproduct identifier data via an application programming interface (API)associated with the componentized operating system; selectively writingthe operating system version data and the product identifier data to theuser viewable location; accessing a hardware device included in theembedded system to acquire a hardware device data; selectively writingthe hardware device data to the user viewable location; accessing aregistry associated with the componentized operating system to acquire asoftware data; and selectively writing the software data to the userviewable location.
 28. The method of claim 26, where the user viewablelocation is a file accessible by a viewing logic.
 29. The method ofclaim 26, where the hardware device data includes a media access control(MAC) address and an Internet Protocol (IP) address.
 30. Acomputer-readable medium storing processor executable instructionsoperable to perform a method for producing a single point of contact fora user to access system information describing elements of an embeddedsystem configured with a componentized operating system, the methodcomprising: selectively writing an embedded system manufacturer data toa user viewable location; retrieving a product name, a serial number, aROM version, a ROM data, and a RAM data for the embedded system via anSMBIOS associated with the embedded system; selectively writing theproduct name, serial number, ROM version, ROM data, and RAM data to theuser viewable location; acquiring an operating system version data and aproduct identifier data via an application programming interface (API)associated with the componentized operating system; selectively writingthe operating system version data and the product identifier data to theuser viewable location; accessing a hardware device included in theembedded system to acquire a hardware device data; selectively writingthe hardware device data to the user viewable location; accessing aregistry associated with the componentized operating system to acquire asoftware data; and selectively writing the software data to the userviewable location.
 31. A system, comprising: means for acquiring ahardware data from an embedded system configured with a componentizedoperating system, where the hardware data describes a hardware componentof the embedded system; means for acquiring a firmware data from theembedded system, where the firmware data describes a firmware componentof the embedded system; means for acquiring a software data from theembedded system, where the software data describes a software componentof the embedded system; and means for providing the hardware data, thefirmware data, and the software data to a single location accessible bya user.
 32. In a computer system having a graphical user interfacecomprising a display and a selection device, a method of providing andselecting from a set of data entries on the display, the methodcomprising: retrieving a set of data entries, where a data entryrepresents an operation associated with collecting and displaying a dataitem that describes an element of an embedded system configured with acomponentized operating system; displaying the set of data entries onthe display; receiving a data entry selection signal indicative of theselection device selecting a selected data entry; and in response to thedata entry selection signal, initiating an operation associated with theselected data entry.
 33. A set of application programming interfacesembodied on a computer-readable medium for execution by a computercomponent in conjunction with collecting and providing a system datathat describes a component of an embedded system configured with acomponentized operating system, comprising: a first interface forcommunicating a first identifier that identifies a system data tocollect; and a second interface for communicating a second identifierthat identifies a system data to provide.